1. Field
The invention concerns communication networks with an IP type core network (IP standing for “Internet Protocol”), and more particularly, access by communication terminals to services that such networks make available to their users.
2. Related Art
Here, “communication network with an IP type core network” is meant to refer to both end-to-end IP networks, in which the user has an IP link, and to networks with an IP-type core network, which can be accessed by another technology via a gateway. Such networks are, for example, those which rely on the technology SIP (for “Session Initiation Protocol”), such as IMS networks (for “IP Multimedia Subsystem” (3GPP)), or MMD (for “Multimedia Domain” (3GPP2)).
Additionally, the term “communication terminal” here refers to any communication device, using radio waves or wired, fixed or mobile (or portable) which can connect to at least one IP network, possibly using a gateway or gateways, in order to exchange data with another device in the form of signals. It may, therefore, be a land-line or mobile telephone, or a desktop or laptop computer, or a personal digital assistant (or PDA) equipped with a communication module, or a server equipped with a communication module that may possibly belong to a provider that delivers the service and that contains a User Agent function.
As is known to a person skilled in the art, certain Internet core networks include service equipments, such as “proxy” servers (or “SIP-proxy”) intended mainly for “smart” routing of SIP signalling, application servers, and MRF (or “Media Resources Function”) entities tasked with providing (calling or called) terminals with communications-related services. Among these services, one may mention in particular prepayment, or CMM services (for “Corporate Mobility Manager”—virtual office), messaging, conferences, portals, kiosks, downloading ringtones, or “push to talk.”
More precisely, when a terminal needs to access a service, either upon initiation by its user or by a core network, it must send an access request for said service to the network on which it is a client. Once this request is received, the network routes it using an SIP proxy server for example to the (or one of the) application server(s) dedicated (at least) to that service, i.e. tasked with managing and controlling the furnishing of the requested service to the calling terminal.
Here, the term “service” is meant to refer to any service that relates, at least in part, to communication whose purpose is to exchange media data streams in any form, such as voice streams (VoIP for “Voice over IP”), video streams or text streams (for instance “chatting”). It is important to note that the streams may be interactive, whether in real-time or not.
Providing these service frequently requires the implementation, by one of the service equipments involved in a communication service, of a complementary function, such as (and not limited to) charging. Now, in a same core network, several service equipments are generally capable of implementing the same complementary function. This is particularly true of the so-called “on-line” charging, used for contacting a server that manages, in real time, the credits that users have. For this reason, in a core network, the SIP proxies and certain application(s) servers are capable of implementing the function of on-line charging.
The disadvantage resides in the fact that neither an SIP proxy nor an application(s) server can know if it must implement its own complementary function, or if another service equipment must do it. Currently, the SIP proxy, which is in charge of communication, always implements its complementary on-line charging function. Frequently, it happens that the application(s) server, which it invoked in order to provide a called service, implements its own complementary on-line charging function in parallel. This may lead to interference. Additionally, this doubles the interactions (signaling exchanges) with the server that manages the on-line charging, and therefore doubles the computing (or CPU) resources used, all while introducing delays in establishing the session.
There are, of course, proprietary solutions that consist of providing service equipments, such as SIP proxies, with local tables that specify which application(s) servers are suitable for implementing complementary functions. However, every time a new service is offered by a core network (and therefore when a new application(s) server is added to that core network), or whenever a new version of an application(s) server is added to that core network, it is necessary to update each SIP proxy's local tables, which requires coordinating maintenance operations (or OAM). Additionally, if an application(s) server, tasked with implementing a complementary function, withdraws from a session, the SIP proxy cannot act as a substitute for it for the purpose of implementing that complementary function.